Today, electronic messages (e.g. e-mails) sent from a sending party to a receiving terminal in or over a communication network, e.g. the Internet or a communication network for mobile terminals, are commonly delivered to their recipients by means of a dedicated protocol, e.g. the Post Office Protocol (POP) or the Internet Message Access Protocol (IMAP). A common characteristic of this approach is that electronic messages directed to a receiving terminal or a recipient arrive at a server (herein called messaging server) associated with the receiving terminal. The messaging server may for example be an e-mail server. The electronic messages are then stored on the messaging server on the behalf of the recipient.
Instead of actually delivering the electronic messages from the messaging server to the receiving terminal, it has become a common usage pattern to use the deliverance protocol, e.g. POP or IMAP, not only as a message retrieval protocol, but as a means to manage (e.g. read, move or delete) electronic messages, e.g. e-mails, while maintaining them at the messaging server. This is a different usage pattern compared with the traditional pattern, in that the electronic messages are never forwarded to the receiving terminal (i.e. sent and removed from the messaging server), but the messages remain stored at the messaging server as long as the receiver or recipient wants to keep the electronic message.
In this usage pattern, the receiving terminal acts as a client only, e.g. an IMAP client or a POP client. The state kept by the receiving terminal is based on the information that the receiving terminal derives from its session(s) with the messaging server. The messaging server may e.g. be implemented as an IMAP server or a POP server, and hence said session(s) may e.g. be IMAP or POP session(s).
Effectively, this means that the receiving terminal or client builds up a cache or copy of the contents in the messaging server. The relation between the messaging server and the receiving terminal or client may be seen as a master-slave situation where the receiving terminal or client is the slave and contains a slave copy of the contents in the messaging server. The cache in the receiving terminal or client includes, e.g., mail bodies (e.g. rfc822 Content) and metadata for the mail bodies (e.g. IMAP flags), as well as folder states. One example of a folder state is the so-called “EXISTS” state which is a value that indicates the number of messages in a folder. The EXISTS state changes when the number of messages in a folder changes, e.g. when a new e-mail arrives or when an e-mail is deleted.
A common pattern for IMAP clients according to the background art, is to either use the method known as “IMAP IDLE” to connect to the messaging server, or to poll the IMAP server (a messaging server configured as IMAP server) for changes in the state of any information or item(s) that is accessible via IMAP. In either case, the IMAP client is notified regarding the state of the IMAP accessible information or item(s). This state often indicates how many messages there are in a folder and the state of the messages (e.g. new, recent, read). By comparing the new state with the cached state, the IMAP client can deduce what has changed and, if a new electronic message has arrived and the client is so configured, retrieve the new electronic message (partly, or in full).
The above described procedure is effectively what an IMAP client goes through every time a state change has occurred at the messaging server, e.g. when a new message has arrived at the messaging server. The effect is that the IMAP client 1) obtains an update of the current state of the IMAP accessible information or items(s) at the messaging server (e.g. the current state of the IMAP INBOX), and 2) downloads any newly arrived electronic messages. In case that other protocols are used, of course the state information available, is state information about information or item(s) that is accessible via that particular protocol (e.g. POP)
If the receiving terminal is an IMAP client, background art solutions require the receiving terminal/IMAP client to manage its state solely based on the data received by the receiving terminal/IMAP client via the IMAP sessions. If the receiving terminal is a POP client, the situation is analogous or similar, although the information conveyed to the receiving terminal is less rich than in the IMAP case. Maintaining or keeping an IMAP or POP session requires either polling the messaging server, or maintaining long lasting Transmission Control Protocol (TCP) connections, both of which cause excessive battery drain in the receiving terminal.
Currently there exist no battery or energy efficient ways of performing the state sharing or state managing for the receiving terminal in the case that the receiving terminal is implemented as an IMAP client or POP client. Of course this is also true for receiving terminals implemented as clients using protocols that are used in a similar way as the IMAP and POP protocols.
FIG. 1 illustrates the technique according to the prior art where a sending party A sends an electronic message D to a messaging server B. The receiving terminal C, e.g. a mobile terminal such as a mobile or cellular phone or a portable computer, associated with a recipient, polls the messaging server B or sets up an IMAP IDLE session to the messaging server B. Through the session(s) with the messaging server the receiving terminal manages its state. As said before, the receiving terminal may e.g. act as an IMAP or POP client.
Transmission of an electronic message from the sending party to the messaging server is normally done using the Short Message Transfer Protocol (SMTP). This provides an expedient delivery of the message to the recipient's messaging server.
Polling is generally deemed acceptable in fixed or wired networks. However, in wireless networks, repeated network traffic, e.g. to poll the messaging server, causes a large drain of the battery in the receiving terminal, e.g. a mobile terminal or a wireless mobile terminal. Moreover, the typically scarce radio resources are unnecessarily loaded or burdened by this repeated polling.
One solution to the problem described above which has been proposed is called the “IMAP IDLE extension”. Once an IMAP session is established, the IMAP IDLE extension allows, d, the receiving terminal to obtain state information from the messaging server. However, one substantial disadvantage with this solution is the requirement to maintain a Transmission Control Protocol (TCP) session from the receiving terminal to the messaging server for the entire time period or duration it should be possible for the receiving terminal to obtain state information from the messaging server.
That is, the TCP session must be constantly maintained. To solve the problem of battery drainage, the TCP session is not allowed to send anything if there are no notifications or electronic messages to send. While this is indeed possible when using the TCP, it is not compatible with Network Address Translation nodes (NAT nodes) which may be present in the path between the messaging server and the receiving terminal. NAT nodes are considered to be transparent and the only way to ensure that a state kept or present in any occurring intermediate NAT node is maintained is to send refresh or update messages (either on TCP level or on higher levels) in order to maintain the TCP session “alive”. This obviously counteracts the battery saving objective.